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PACKET SERVICE SYSTEM AND METHOD FOR CONTROLLmO PACKET 

TRANSMISSION 



Technical Field 

5 The present invention relates to a communication system, and more particularly, to a 
packet service system and method of controlling packet transmission. 



Background Art 

In the world of cellular telecommunications, those skilled in the art often use the terms 

10 IG, 2G, and 30. The terms refer to the generation of the cellular technology used. IG 
refers to the first generation, 2G to the second generation, and 3G to the third generation. 
IG is used to refer to the analog phone system, known as an AMPS (Advanced Mobile 
Phone Service) phone systems. 2G is commonly used to refer to the digital cellular 
systems that are prevalent throughout the world, and include CDMAOne, Global System 

15 for Mobile communications (GSM), and Time Division Multiple Access (TDMA). 2G 
systems can support a greater number of users in a dense area than can IG systems. 
3G is commonly used to refer to the digital cellular systems currently being developed. 
Recently, third-generation (3G) CDMA communication systems have been proposed 
including proposals, such as cdma2000 and W-CDMA. These 3G communication 

2 0 systems are conceptually similar to each other with some significant differences. 

A W-CDMA system is a third-generation (3G) wideband, asynchronous, spread spectrum 
radio interface system which uses the enhanced service potential of CDMA technology to 
facilitate data capabilities, such as Internet and intranet access, multimedia applications, 
high-speed business transactions, and telemetry. The focus of W-CDMA, as is that of 

25 other third-generation systems, is on network economy and radio transmission design to 
overcome the limitations of a finite amount of radio spectrum availability. 
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Under the currently proposed W-CDMA system standard, each of the base stations 
operates asynchronously. In other words, there is no universal time reference among 
separate base stations. In the W-CDMA system, each base station transmits a 
"synchronization" channel that comprises two sub-channels. 
5 The first of the two sub-channels, the primary synchronization channel, uses a primary 
synchronization code that is common to all base stations. The second of the two sub- 
channels, the secondary synchronization channel, uses a cyclic set of secondary 
synchronization codes. The secondary synchronization codes are not shared by other 
base stations that are not in the same code group. The mobile station in a W-CDMA 
10 system can acquire the synchronization channel of one or more base stations by searching 
for the primary synchronization code of the primary synchronization channel, and then 
using the timing information derived from the primary synchronization channel to 
process the secondary synchronization channel. 

The International Telecommunications Union (FTU) originally spearheaded tiie 3G (Third 
15 Generation) standard for mobile communications systems, pursuant to the International 
Mobile Telephony 2000 (IMT2000) project. IMT2000 provides a vision for a single 
global standard for wireless networks perceived as the global 30 system. In a 3G system, 
the next generation of mobile communications systems will offer enhanced services, such 
as multimedia and video. The main 3G technologies include Universal Mobile 
2 0 Telecommunications System (UMTS) and CDMA2000. 

UMTS provides an enhanced range of multimedia services. UMTS will speed 
convergence between telecommunications, information technology, media and content 
industries to deliver new services and create fresh revenue generating opportunities. 
UMTS will deliver low cost, high capacity mobile communications offering data rates as 
25 high as 2 Mbps under stationary conditions with global roaming and other advanced 
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capabilities. The specifications defining UMTS are formulated by Third Generation 
Partnership Project (3GPP). 

UMTS is a next generation mobile communication system evolving fi-om GSM (global 
system for mobile communications) European standard. FIG. 1 is a block diagram of 
5 architecture of a general UMTS. Referring to FIG. 1, UMTS consists of a user 
equipment (UE) 100 (also referred to as a mobile station), a universal mobile 
telecommunications network terrestrial radio access network (hereinafter abbreviated 
UTRAN) 200, and a core network 300. UTRAN 200 consists of a plurality of ratio 
network subsystems 10a to lOn. 

10 For instance, one radio network subsystem 10a consists of one radio network controller 
(hereinafter abbreviated RNC) 12 and a plurality of Nodes B 11a and 1 lb. The Nodes B 
1 la and 1 lb are managed by the RNC 12. Each of the radio network subsystems 10b to 
lOn has the same construction of the above-pxplained radio network subsystem 10a. 
Nodes B 1 la/1 lb and 13a/13b receive uplink data transmitted from the user equipment 

15 100 or transmit downlink data to the user equipment 100. 

RNCs 12 and 14 allocate and manage radio resources. RNCs 12 and 14 play a role of 
access points to connect Nodes B 1 la/1 lb and 13a/13b to the core network 200, 
respectively. And, Nodes B 1 la/1 lb and 13a/13b play a role of access points to connect 
the user equipment 100 to UTRAN 200. 

20 In the above-explained construction, if the user equipment 100 is being connected to a 
network, the RNC managing the user equipment 100 is a serving RNC (SRNC). In this 
case, SRNC plays a role in connecting the user equipment 100 to the core network 300. 
And, the SRNC allocates a radio resource appropriate for providing the user equipment 
with a specific service. 

25 Services provided to the user equipment 100 through the above construction can be 
divided into a circuit switched service and a packet switched service. For instance, a 
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general voice calling service belongs to the circuit switched service and a web browsing 
service via Internet access belongs to the packet switched service. 
When the system m FIG. 1 supports the circuit switched service, RNCs 12 and 14 are 
connected to a mobile switching center (hereinafter abbreviated MSC) 20 of the core 
5 network 300. MSC 20 is then coimected to GMSC (gateway mobile switching center) 30. 
GMSC 30 manages access of a voice call requested fiom or to an external network. 
When the system in FIG. 1 supports the packet switched service, RNCs 12 and 14 are 
connected to a serving GPRS (general packet radio service) support node (hereinafter 
abbreviated SGSN) 40 and a gateway GPRS support node (hereinafter abbreviated 

1 0 GGSN) 50 of the core network 300. 

In this case, GGSN 50 plays a role of a gateway for interworking with Intemet or external 
network. Moreover, SGSN 40 is connected to GGSN 50 to manage mobility of the user 
equipment 100 and to perform a packet switch function. Interfaces for mutual 
communication are defined between various elements constructing the system in FIG. 1. 

15 lu interface is defined between the RNCs 12 and 14 and the core network 300. lu 
interface connected to an element in a packet switched area is dejBned as lu-PS. lu 
interface connected to an element in a circuit switched area is defined as lu-CS. The 
UMTS shown in FIG, 1 is established to provide a variety of multimedia services 
guaranteeing a quality over a predetermined level. 

20 An overall quality of service, which determmes user's satisfaction for a specific service is 
defined as quality of service (hereinafter abbreviated QoS). QoS experienced by a user 
depends on various and complicated factors applied to the respective services. 
High transmission rate or speed in wireless or wired line fails to satisfy user-requested 
QoS. Namely, transmission capacity (or speed) in all end-to-end transport paths including 

25 both of the wire and wireless lines should be guaranteed over a predetermined level as 
well as the transmission rate in the wireless line. 
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In UMTS, concepts of various bearer services are defined to guarantee QoS over a 
predetermined level for an end-to-end specific service. Specifically, an end-to-end 
specific conununication service is divided into several lines (e.g., wired line, wireless 
line) through various network elements to be provided. Hence, data transfer service is 
5 independently defined in each line and each QoS for the defined service is guaranteed. 
Specifically, a bearer in charge of reliable transmission of user data in a line between the 
user equipment and the core network 300 is called a radio access bearer (hereinafter 
abbreviated RAB). RAB is implemented through a radio bearer service and an lu bearer 
service. 

1 0 The radio bearer service is to transmit data using lu interface between the user equipment 
100 and the RNCs 12 and 14, and the lu bearer service is to perform data transmission 
between the RNCs 12 and 14 and the core network 300. 

RAB should be firstly configured to provide a specific service. In configuring RAB, 
various parameters are set to satisfy specific QoS. MSG 20 initiates to configure RAB in 
15 the circuit switched service, whereas SGSN 40 initiates to configure RAB in the packet 
switched service. 

The 3GPP (3rd generation partnership project) created for next generation standardization 
of UMTS specifies radio interface protocol architecture between user equipment and 
UTRAN. FIG. 2 is a diagram of radio interface protocol architecture between user 
2 0 equipment and UTRAN based on 3 GPP radio access network specifications. 

Referring to FIG. 2, a radio interface protocol sets up, reconfigures, and releases the radio 
bearer services. The radio interfece protocol is equipped with functions corresponding to 
layers 1 to 3 (LI to L3), i.e., physical, link, and network layers. 

LI, i.e. physical layer, offers information transfer services to MAC sublayer and higher 
25 layers. LI offers separate transport channels to the MAC sublayer. The transport channel 
is characterized by how data is transferred on the radio interface. L2 consists of a 
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medium access control (MAC) sublayer, a radio link control (RLC) sublayer, a packet 
data convergence protocol sublayer, and a broadcast/multicast sublayer. 
The MAC sublayer offers separate logical channels to RLC, and one logical channel is 
characterized by a transferred information type. The MAC sublayer offers data transfer 
5 services through the logical channels. Such channels are grouped into two kinds, such as 
control channels for control plane information transfer, and traffic channels for user plane 
information transfer. 

Reallocation services of radio resources and MAC parameters offer services to higher 
layers by the MAC sublayer. The reallocation services are performed by an execution 
10 request of RRC for changing MAC parameters and reallocatmg the radio resources. The 
MAC sublayer itself handles the resource allocation. 

And, the MAC sublayer consists of various entities such as MAC-b, MAC-d, and MAC- 
s/sh. The RLC sublayer supports reliable data transfer services. The RLC sublayer 
segments protocol data units (hereinafter abbreviated PDUs) of higher layer into RLC 
15 service data units (hereinafter abbreviated SDUs) or reassembles RLC SDUs into PDUs 
of higher layers. 

The broadcast/multicast control (hereinafter abbreviated BMC) sublayer offers 
broadcast/multicast transmission services in user plane. Basic Amotions of the BMC 
sublayer are storage of cell broadcast messages (CBs), radio resource request for traffic 
20 volume monitoring and cell broadcast service, scheduling of BMC messages, and 
delivery of BMS messages to user equipment. And, the PDCP sublayer offers 
transmission/reception of network PDUs. 

L3 includes sublayers on control plane. A radio resource control (hereinafter abbreviated 
RRC) layer as the lowest one of the sublayers of L3 is equipped with the following 
25 ftmctions. 
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The RRC layer takes charge of establishment, reestablishment, maintenance, and release 
of RRC connection between UE (user equipment) and UTRAN. The RRC layer also 
takes charge of setup, reconfiguration, and release of radio bearers (hereinafter 
abbreviated RBs) on user plane. The RRC layer also takes charge of allocation, 
5 reconfiguration, and release of radio resources for RRC connection. 

3GPP using the above-explained radio interface protocol architecture is trying to develop 
standardization specifications for the broadcast/multicast services (hereinafter 
abbreviated MBMS), MBMS intends to overcome such limitations of the previous cell 
broadcast service (CBS) as failure of supporting multicast function, restriction of 
1 0 supportable media data, and the like. 

Hence, MBMS uses a unidirectional point-to-multipoint bearer service to simultaneously 
deliver multimedia data of audio, pictures, video, etc. to a multitude of UEs, MBMS is 
divided into a broadcast mode and a multicast mode. 

In MBMS broadcast mode, multimedia data is transmitted to all UEs in a broadcast 

1 5 domain where broadcast services are available. 

In MBMS multicast mode, multimedia data is transmitted to a specific UE group in a 
multicast domain where multicast services are available. In order to be provided with 
MBMS in multicast mode, UE should subscribe in a multicast subscription group. UE 
then enables to receive specific multicast data after completion of subscription. 

2 0 Set up requirement information for MBMS is implemented by the configuration of RAB. 
Namely, for MBMS, RAB of MBMS for guaranteeing QoS exceeding a specific level 
should be set up between UE and core network. 

MBMS uses a real-time transport protocol (hereinafter abbreviated RTF) in transmitting 
real-time data. The real-time data has a packet type transmitted on real time and is 
2 5 depicted as real-time packet in the following. 
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RTP is a protocol made appropriate for transmitting multimedia data having a real-time 
transmission attribute such as audio data, video data, etc. over a multicast or unicast 
network. RTP itself is unable to guarantee QoS for such a real-time service as voice 
service, video service, etc. Hence, MBMS further uses an RTP control protocol 
5 (hereinafter abbreviated RTCP). 

Implemented for wired line communication, the RTP and RTCP have diflBculty in 
offering services via both wire and wireless lines through the system shown in FIG. 2. 
Namely, direct application of the RTP and RTCP to the wireless line brings about the 
following problems. 

10 First, an RTCP packet for transferring status information of the RTP packet to a data 
source fails to distinguish between packet loss occurring in the wire or the wireless lines. 
The RTCP packet checks the packet loss amount due to collision in the wired line only to 
monitor data flow in a network. The data source cannot determine if the packet loss 
occurs in the wireless line or the wired line. 

15 In a UMTS network, the packet loss amount in the wireless line is generally greater than 
that in the wired line. Hence, it is highly probable that the data source commits errors in 
handling the transmission of subsequent RTP packets based on the RTCP packet. 
For instance, the data source monitors the current situation of the network from the status 
information included in the RTCP packet, and changes a size of RTCP packet to be 

2 0 transmitted and an encoding scheme according to a result of the monitoring to reduce the 
loss of the subsequent packets &at will be transmitted later. 

The cause of the packet loss in tiie wired line is different from that in the wireless line. 
Hence, the size and encoding scheme of the RTP packet to be transmitted should be 
appropriately changed according to the respective causes of the wire and wireless lines. 
25 In the related art, there is no way for the data source to differentiate the packet loss cause 
in the wired Ime from that m the wireless line. Related art systems are unable to 
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effectively perform the transmission handling and control in the wire and/or wireless 
networks to reduce the error occurrence during RTP packet transmission. 
Further, if there are a plurality of UEs receiving services like MBMS, RTCP packets are 
transmitted to the data source fiom the respective UEs so as to bring about a problem in 
5 detennining each bandwidth required for transmission of RTP and RTCP packets. 

Specifically, since RTP and RTCP are protocols made appropriate for the wired line only, 
there exists one UE (or host) at a terminal end of the wired line. Hence, if such a point-to- 
multipoint communication as MBMS uses the related art RTP and RTCP wittiout 
modification, there occurs a problem of assigning a bandwidth required for packet 
1 0 transmission to reduce efficiency of resource use. 

Disclosure of Inventiop 

A method of transferring real-time data from a data source to a mobile device in 
communication with a communications network having a wired conamunication line and 

15 a wireless communication line is provided. The method comprises receiving the real- 
time data from the data source over the wired communication line; detennining packet 
loss for the wired communication line to produce control information; transmitting 
the control information to the data source; transmitting the real-time data to the mobile 
device over the wired and wireless communication lines based on the control 

20 information. 

In one embodiment, the method fiirther comprises determining quality of service data for 
at least one of the wired or wireless communication lines based on the control 
information; adjusting transmission requirements for the real-time data based on the 
quality of service data; adjusting transmission size of real-time data packets comprising 
25 the real-time data; and adjusting encoding mode of the real-time data. The adjusting is 
performed when real-time data is transmitted from the data source. 
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The quality of service for the wireless communication line is determined based on a first 
quality of service associated with the communications network segment that controls 
communication of real-time data fiom the data source to the mobile device and a second 
quality of service associated with the wired commimication line. In one embodiment, 
5 the quality of service for the wireless communication line is determined based on first 
and second quality of service information. 

The first quality of service information is received fi'om the mobile device. The second 
quality of service information is determined based on receiving loss packet information 
for the real-time data communicated over the wired conmiunication line. The first quality 
10 of service information is determined based on number of packets lost during 
communication of &e real-time data firom the data source to the mobile device over the 
wired and wireless communication lines. The real-time data is received and transmitted 
over a real-time transport protocol (RTP). 

The real-time data is received and transmitted via a mobile communications network in 
15 communication with the data source. A UMTS terrestrial radio access network 
(UTRAN) determines the quality of service for the wireless communication line based on 
first packet loss information received from the mobile device and second packet loss 
information associated with receiving the data over the wired communication line. 
In one embodiment, the UTRAN comprises a relay function module for depacketizing the 
20 real-time data received over the wured confununication line to determining the second 
packet loss information. The relay fimction module packetizes the depacketized real-time 
data before transmitting it to the mobile device. The mobile device sends a feedback 
comprising the first packet loss information to the UTRAN after receiving the real-time 
data. 
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The real-time data is encapsulated in real-time transport protocol (RTP) packets 
transmitted over user data gram protocol (UDP). The real-time data is transported via 
real-time transport control protocol (RTCP). 

In one embodiment, a real-time data communication system comprises a wired 
5 communication system connected to a data source; and an interface system for wirelessly 
connecting the wired communication system to a mobile device; wherein the interface 
system adjusts transmission requirements for real-time data based on first packet loss 
information associated with real-time data transmitted over the wired conmiunication 
system. 

10 A first quality of service is determined based on transmission of the real-time data firom 
the data source to the interface system. A second quality of service is determined based 
on transmission of the real-time data fh)m the interface system to the mobile device. The 
interface system comprises a relay module for processing data transmitted from the data 
source to the mobile device. If the data transmitted is not real-time data then the relay 

15 module does not process the data. If the data is not transmitted over real-time control 
protocol then the relay module does not process the data. 

In one embodiment, a first quality of service is determined by the relay module by 
depacketizing real-time data transmitted over the real-time control protocol to determine 
packet loss in the wired communication system. A second quality of service is 

20 determined by the relay module based on feedback provided by mobile device about 
packet loss detected after receipt of real-time data by the mobile device. 
The real-time data is encapsulated in ^ real-time transport protocol (RTP) packets 
transmitted over user data gram protocol (UDP). And, The real-time data is transported 
via real-time transport control protocol (RTCP), for example. 

25 In yet another embodiment, a method of data communication comprises establishing a 
communication bearer between a data source and a mobile device over a communication 
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network comprising wired and wireless communication segments; and adjusting 
transmission of ttie real-time data based on quality of service over the wired and wireless 
communication segments, when data being communicated comprises real-time data and 
is being transmitted over a real-time communication protocol. 
5 A relay module determines the quality of service over the wireless communication 
segment by receiving feedback from the mobile device over a real-time control protocol 
and comparing the feed back with quality of service information for the wired 
conununication segment. The relay module is incorporated into a communications 
network connecting the data source and the mobile device. A radio access bearer (RAB) 
10 is established between the commimications network and the mobile device to provide the 
relay module with quality of service information. 

In another embodiment, a method of transferring real-time data from a data source to a 
mobile device connected to a wked communication line by way of a wireless 
communication line, wherein a Universal Terrestrial Radio Network (UTRAN) acts as a 

15 communication interface between the wired and wireless communication lines is provider. 
The method comprises receiving the real-time data from the data source over the wired 
communication line; tmnsmitting control information associated with transmission 
quality of real-time data over the wired communication line to the data source; and 
transmitting the real-time data to the mobile device over the wireless communication line 

2 0 based on the control information. 

Brief Description of Drawings 

The accompanying drawings, which are included to provide a further understanding of 
the invention and are incorporated in and constitute a part of this application, illustrate 
25 embodiment(s) of the invention and together with the description serve to explain the 
principle of the invention. 
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FIG. 1 is a block diagram of architecture of a general UMTS; 

FIG. 2 is a diagram of Radio Interface protocol architecture between user equipment and 
UTRAN based on 3GPP radio access network specifications; 

FIG. 3 is a diagram of UMTS for explaining real-time/non-real-time packet flow 
5 according to one embodiment of the present invention; 

FIG. 4 is a diagram of protocol architecture for explaming real-time/non-real-time packet 
flow according to one embodiment of the present invention; and 
FIG. S is a flowchart of a procedure of handling real-time/non-real-time packets 
according to one embodiment of the present invention. 
10 FIG. 6 illustrates a block diagram of mobile station according to the preferred 
embodiment of the present invention. 

Reference will now be made in detail to the preferred embodiments of the present 
invention, examples of which are illustrated in the accompanying drawings. Wherever 
possible, the same reference numbers will be used throughout the drawings to refer to the 
1 5 same or like parts. 

Best Mode for Carrying Out the Invention 

To aid describing the present invention, certain exemplary parameter names, values, 
lengths and other attributes are bemg used to describe the channels, messages and fix or 
2 0 variable identifiers communicated between mobile and base stations. It should be noted 
that such parameter names are for illustration purposes only, and that other names may be 
used to describe the same or similar function. 

Referring to FIG. 3, a packet service system according to the present invention comprises 
a data source, a core network, a UTRAN, and a user equipment (UE). The data source is 
25 the beginning point of a wired line and the user equipment is the end point of a wireless 
line. 
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The UTRAN is an end point of the wired line as well as a beginning point of the wireless 
line. The user equipment is a terminal over the wireless, and the UTRAN is a radio access 
network providing the user equipment with access wireless to the UTRAN using a packet 
service offered by the data source. 
5 The data source and the user equipment are equipped with protocol layers for real-time 
packet services. For instance, the data source downwardly contains an RTP layer and an 
RTCP layer and furflier contains a UDP/IP (user datagram protocol/lhtemet protocol) 
layer below the RTP/RTCP layers. The user equipment contains the above-mentioned 
protocol layers of the data source as well. Moreover, the data source and user equipment 

1 0 contain protocol layers for non-real-time packet services. 

In one embodiment, the present invention is characterized in that UTRAN comprises 
RTP and RTCP layers over UDP/IP layer to support real-time packet services. UTRAN 
further supports non-real-time packet services as well. UTRAN plays a role in 
transferring non-real-time packets transparently. 

15 The RTP layer of UTRAN relays real-time data sent from the data source to UE, and the 
RTCP layer controls transmission of the real-time data. The UTRAN further comprises a 
UDP/IP (user datagram protocol/Intemet protocol) layer below the RTP/RTCP layers. 
The real-time data transmitted/received between the data source and UTRAN or between 
UE and UTRAN is RTP/UDP/IP packet. The corresponding RTP/UDP/IP layer extracts 

20 the received RTP/UDP/IP packet and converts it to a RTP or RTCP packet 

In the above description, it is explained that the UTRAN includes the RTP/RTCP layers 
over UDP/BP layer performing operations, which is for minimizing the structural 
alteration of the UTRAN. Specifically, the UTRAN of the present invention includes a 
function entity performing an operation by the RTP layer and an operation by the RTCP 

25 layer. A function entity relay function module is installed in RNC as an element of the 
UTRAN, in accordance with one embodiment, for example. The relay function module 
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discerns wired line and wireless line from each other. An example of using the relay 
function module according to the present invention is shown in FIG. 3 and protocol 
architecture required for implementing the relay function module is shown in FIG. 4. 
Relay function modules in FIG. 3 are explained as follows. First, a plurality of relay 
5 function modules 80a to 80n provide independent operations of RTP/RTCP in each of 
wire and wireless lines for real-time packets such as RTP packets. In this case, the 
wireless line lies between UTRAN 200 and UE 100 and the wired line lies between the 
UTRAN 200 and a data source 70. 

Second, the relay function modules 80a to 80n are used in a system for transmitting RTP 

10 and RTCP packets like MBMS. In such a system, the relay function modules 80a to 80n 
generate RTCP packets carrying receiving status information of the wired line, and 
transmit RTP packets to the UEs 100 in the wireless section to handle RTCP packets 
carrying status information of the wireless line from the UEs 100. 
Third, the relay function modules 80a to 80n are installed in the UTRAN 200 performing 

15 the control of packet transmission of the wireless line. The relay function modules 80a to 
80n are connected to RNCs 12a to 12n of the UTRAN 200. In implementing the system, 
the relay function modules 80a to 80n can be installed in the RNCs 12a to 12n, 
respectively or installed in the UTRAN 200 to be separated from the RNCs 12a to 12n. 
Once the relay function modules 80a to 80n are coimected to the RNCs 12a to 12n to 

20 operate, respectively, the connection thereof is achieved by 'tunneling'. Namely, the 
relay function modules 80a to 80n are connected to the RNCs 12a to 12n, respectively by 
tunneling to perform flow and handling controls of packets in the wire/wireless lines. 
Thus, if the relay function modules 80a to 80n are used as one element of the UTRAN 
200, protocol layers executed by the relay function modules 80a to 80n to provide an 

25 efficient operation of RTCP in each Hne, as shown in FIG. 3, are defined as shown in FIG. 
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RTP/RTCP corresponding to functions of the relay function modules 80a to 80n, a user 
datagram protocol (UDP) layer, and Internet protocol (IP) layers are further provided 
above radio and network access protocols of the UTRAN 200. 

Operations of the relay function modules 80a to 80n are explained in the following by 
5 taking a case of installing the relay function modules 80a to 80n in the RNCs 12a to 12n 
of the UTRAN 200, respectively as an example. 

The relay function modules 80a to 80n generate control packets carrying reception status 
information for the wired line when such data packet data packets having real-time 
attributes as RTP packets transmitted from the data source 70 are received. The relay 
1 0 function modules 80a to 80n then provide the generated control packets to the data source 
70. 

In one embodiment, the data source 70 regards the control packets transmitted from the 
relay function modules 80a to 80n as being transmitted at the ending point of each of the 
wire and/or wireless lines and determines bandwidths required for transmissions of data 
15 packet data packets (e.g., RTP packets) and control packets (e.g., RTCP packets), 
respectively. 

The relay function modules 80a to 80n broadcast and/or multicast the data packets of the 
real-time attribute to a plurality of UEs on a downlink radio channel and then receive 
control packets generated from the UEs having received the data packets to acquire the 

2 0 reception status information of the current wireless line. 

The relay function modules 80a to 80n or RNCs 12a to 12n perform the control of packet 
transmission on the data packets using the reception status information of the wireless 
line acquired from the control packets. In case that the RNCs 12a to 12n of the UTRAN 
200 provide the control information of the data packets transmitted from the data source, 

25 the relay function modules 80a to 80n offer the reception status information of the wired 
line to the data source. 
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Consequently, one subject (data source) performing the control of the packet transmission 
from the reception status information of the wired line is independent from the other 
subject (RNC) performing the control of the packet transmission from the reception status 
information of the wireless line. 
5 For another instance, each of the relay function modules 80a to 80n of the present 
invention adds the reception status information of the wireless line acquired from the 
control packet of the UE 1 00 to the corresponding control packet ttiat will be delivered to 
the data source 70 and then transmits it. 

In one embodiment, the packets transmitted to the UE 100 from the data source 70 are 
10 data packets of non-real-time attribute as well as the data packets of the real-time 
attribute. Yet, the relay function modules 80a to 8Qn support and control packet 
transmission of a data packet data packet having the real-time attribute such as RTP 
packets. 

Accordingly, the core network 300 determines the attribute of the data packet that will be 
15 transmitted from the data source 70 and uses a specific indicator to operate the relay 
fimction modules 80a to 80n if the attribute of the detOTnined data packet is real-time. 
Thus, the present invention, in one embodiment, uses the indicator so that the use of the 
relay function modules 80a to 80n supporting the control of the real-time packet 
transmission in the system for supporting both the real-time packet and the non-real-time 
2 0 packet transmission does not interrupt the transmission of the non-real-time packet. 

In another embodiment, the present invention uses the indicator so that the use of the 
relay fimction modules 80a to 80n does not interrupt Hie transmission of the real-time 
packet when the control packet, and particularly, RTCP packet are not needed. 
The core network 300 determines whether the attribute of the current data packet that will 
25 be transmitted from the data source 70 is real-time or non-real-time. The core network 
300 informs the UTRAN 200 that is a termination of the wired line of the determined 
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attribute of the data packet when a radio access bearer for the packet transmission to the 
UE is set up. 

A packet service system according to the present invention is implemented throu^ the 
protocol architecture shown in FIG. 4 and is applicable to the service of transmitting real- 
5 time data such as MBMS. The packet service system according to the present invention is 
applicable to a service of supporting real-time and non-real-time data simultaneously. 
Referring to FIG. 4, RTF is a protocol appropriate for providing a user with multimedia 
data (video and/or audio) having a real-time attribute using a multicast or unicast network. 
A packet format dejSned by RTF comprises an RTF media type field for expressing an 

1 0 RTF media type and further includes a payload containing the substantially serviced user 
information. The RTF media type field is for informing a type of the payload. 
RTCF is a protocol for monitoring data transmission in the multicast network and 
performing minimal control and identification fimctions. Major fimctions of RTCF are to 
generate status information for distributing data to network elements belonging to the 

1 5 multicast network and to feed back the status information to a data source, for example. 
Some functions of the RTCF are related to a flow control and a congestion control of 
other protocols. For example, the status information feedback through the RTCF contains 
the information (e.g., information of an RTF packet loss amount, delay time occurring 
during packet transmission, etc.) of a transmission process of the RTF packet from an 

20 originating place transmitted the RTF packet to a destination receiving the RTF packet. 
The RTCF packet can carry the reception status information. 

Once the RTCF packet for the received RTF packet is fed back to the originating place 
from the destination, the originating place determines data size and/or data amount and/or 
data coding scheme of an RTF packet that will be transmitted, using the status 
2 5 information included in the RTCF packet. 
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For example, in one embodiment of the present invention, UTRAN transfers the RTCP 
packet carrying the status information for the received RTP packet to the data source and 
a user equipment (UE) transmits the RTCP packet to the UTRAN. The RTC3* packet is 
the control packet containing status information enabling a receiving side of the RTCP 
5 packet to perform the control of the transmission of a data packet (RTP packet). 

The UTRAN determines the data size and/or data amoimt and/or data encoding scheme 
of an RTP packet that will be transmitted to the UE using the status information included 
in the RTCP packet received from the UE. The data source determines the data size 
and/or data amount and/or data coding scheme of an RTP packet that will be transmitted 
10 to the UTRAN using the status information included in the RTCP packet received from 
the UTRAN. 

In one embodiment of the present invention, an indicator is used for indicating whether to 
use the relay function module in UTRAN. The indicator is generated from a core network 
monitoring an attribute of a packet generated from the data source. The core network 
15 generates the indicator when a radio access bearer for a packet service originated from 
the data source is set up. The indicator represents the attribute of the packet generated 
from the data source, and is transferred to the UTRAN. 

The UTRAN in one embodiment comprises RTP and RTCP layers over the UDP/IP layer 
for transmission of real-time packets. The relay function module is preferably operated 
20 by the indicator received from the core network. Namely, the core network executes 
control operations of the relay function module using the indicator. In other words, the 
indicator generated from the core netv^ork is a command for turning on/off the operations 
of the relay function module. 

Referring to FIG. 3, the data source 70 enables to transfer a packet of the real-time or 
25 non-real-time attribute. In this case, the data source 70 is a server or terminal offering 
specific data as a packet format. The core network 300 determines the attribute of the 
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packet to be transmitted from the data source 70 and then informs the UTRAN 200 as a 
termination of the wired line of the determined attribute of the packet to be transmitted. 
When a radio access bearer for the packet transmission between the core network 300 and 
the UE 100 is set up, each of the SGSNs 40a to 40n of the core network 300 informs the 
5 UTRAN 70 whether the packet to be transmitted from the data source 70 has the non- 
real-time or real-time attribute. The SGSNs 40a to 40n of the core network 300 use one 
indicator to inform the attribute of the packet to be transmitted fix>m the data source 70. 
In one embodiment of the present invention, the indicator is not limited to inform the 
attribute of the current packet. The SGSNs 40a to 40n of the core network 300 utilizes the 

10 indicator in informing whether to use RTP/RTCP and/or the relay function modules 80a 
to 80n included in the UTRAN 200 as well as the attribute of ttie packet to be transmitted. 
In case that the indicator informs the attribute of the packet to be transmitted, the 
UTRAN 200 determines whether to use the relay function modules SOa to 80n, m 
accordance with the attribute of the packet indicated by the received indicator. 

15 Moreover, when the indicator informs the UTRAN of whether to use the relay function 
modules SOa to 80n. The UTRAN 200 can check whether the packet to be currently 
received has the real-time or non-real-time attribute from the information indicated by the 
received indicator, for example. 

In one embodiment of the present invention, the UTRAN 200 comprises the wired line 
2 0 device for receiving a packet from the data source 70. The control of packet transmission 
in the wired line is supported according to the reception status information of the wired 
line. The wireless line device transmits the packet to the UE 100 to perform the control 
of packet transmission in the wireless line according to the reception status information 
of die wireless line. 

25 Preferably, the UTRAN 200 of the present invention comprises the relay function 
modules SOa to SOn. hi one embodiment, the relay function modules SOa to 80n are 
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installed in the RNCs 12a to 12n, respectively as shown in FIG. 3. Accordingly, the 
UTRAN 200 turns on/off operations of the relay function modules 80a to 80n according 
to the command of the indicator received from the corresponding one of the SGSN 40a to 
40n of the core network 300, when the radio access bearer is setup. 
5 Once a packet is transmitted from the data source 70, each of the GGSN 50a to 50n acts 
as a gateway for interworking with the network to which the data source belongs to 
deliver the corresponding packet to the SGSNs 40a to 40n. Each of the SGSNs 40a to 
40n determines the attribute of the packet to be transmitted to the UE 100 and then 
delivers the indicator for informing the attribute of the corresponding packet to the 
1 0 UTRAN 200. If the determined attribute of the packet in real-time is good as that of the 
RTP packet, then the RTCP informs the data source 70 of the reception status 
information of the real-time packet via the core network 300, by way of being included in 
the indicator. 

In one embodiment, the UTRAN 200 determines the attribute of the packet and/or 
15 whether to use the relay ftmction modules 80a to 80n from the indicator delivered from 
the core network 300. Whether to use the relay ftmction modules 80a to 80n can be 
further included in the indicator to deliver. That is, in case of providing the non-real-time 
packet service, the relay function modules 80a to 80n are not operated and the packet is 
transparently transmitted from the data source to the UE. Each of the SGSNs 40a to 40n 
2 0 delivers the real-time or non-real-time packet to the RNCs 12a to 12n of the UTRAN 200. 
The relay function modules 80a to 80n of the UTRAN 200 operate if the packet to be 
delivered to the UE 100 is real-time and when the RTCP is used. If non-real-time, they do 
not operate. If the RTCP is not used even though the packet to be delivered is real-time, 
the relay function modules 80a to 80n do not operate. The operation of the relay function 
2 5 modules 80a to 80n is controlled by the indicator received from the corresponding one of 
the SGSNs 40ato40n. 
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For instance, when the RTP packet is transmitted from the data source 70 to the UE 100 
as a final destination, the data source 70 should be able to monitor the network status as a 
loss amount of the RTP packet during the packet transmission via the UTRAN 200 in the 
middle of the wire and wireless lines. In one embodiment, the relay function modules 80a 
5 to 80n feed back the RTCP packet containing the reception status information of the 
wired line to the data source 70. 

The RNCs 12a to 12n equipped with the relay function modules 80a to 80n, respectively 
transmit the packet received from the corresponding one of the SGSNs 40a to 40n to the 
UE by wireless line. In this case, if the service is the multicast service, the RNCs 12a to 

10 12n transmit the packet to a plurality of UEs located in their service domain. If the packet 
received from the corresponding one of the SGSNs 40a to 40n is a real-time packet, the 
relay function modules 80a to 80n transmit the real-time packet to the UEs. 
The relay function modules 80a to 80n feed back control packets (e.g., RTCP packets) 
containing the reception status information of the real-time packet to the data source 70 

15 and receive control packets (e.g., RTCP packet) containing the reception status 
information of the wireless line from the UEs, respectively. 

In one embodiment, each status information of the control packets received from the UEs 
is included in the corresponding one of the control packets to be fed back to the data 
source 70. The relay function modules 80a to 80n installed in the RNCs 12a to 12n, 
20 respectively provide the data source 70 with the reception status information of the UEs 
from the control packets received fix)m the Ues. 

In another embodiment, it is preferable for each control packet fed back to the data source 
70 does not contain the reception status information of the wireless line, whereby the 
control packets (RTCP packets received from the UEs) containing the reception status 
25 information of the wireless line are handled by the RNCs 12a to 12n, respectively. The 
RNCs 12a to 12n determine sizes and/or amounts and/or coding schemes of packets to be 
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transmitted to the wireless line based on the control packets received from the UEs, 
respectively. 

In the foregoing description, it is explained that the relay function modules 80a to 80n 
used in discerning statuses of the wire and wireless lines in the flow of the real-time/non- 
5 real-time packets are installed in the RNCs 12a to 12n, respectively. Yet, the relay 
function modules 80a to 80n can be independently installed in the UTRAN 200 from the 
RNCs 12a to 12n. Furthermore, the RNCs 12a to 12n can be implemented to perform 
functions including the function of the relay function modules 80a to 80n. In an 
exemplary embodiment, the relay function modules 80a to 80n are installed at the RNCs 
10 12a to 12n, respectively. Examples of transferring the indicator to the UTRAN 200 in the 
present invention are explained as follows. 

When the relay function modules 80a to 80n are turned on/ofF according to a coiranand of 
the indicator, and when a packet of an attribute is to be transmitted from the data source 
70, the core network 300 delivers the indicator indicating the attribute of the packet to be 
15 transmitted to the UTRAN 200. Such an indicator indicates whether a packet has a real- 
time or non-real-time attribute and whether the control packet, such as RTCP packet, is 
used. 

Hence, if the real-time packet is received after the indicator informing the packet 
transmission of the real-time attribute and the using of RTCP packet is received from the 

2 0 core network, the relay function modules 80a to 80n inform the data source 70 of the 
status information for the real-time packet in the wired line. Yet, if the indicator 
informing the packet transmission of the non-real-time attribute is received from the core 
network 300, the relay function modules 80a to 80n are not involved in the non-real-time 
packet transmission at all. 

25 The relay function modules 80a to 80n are turned off by the command of the indicator, 
when a non-real time packet attribute is transferred from the data source 70. The core 
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network 300 transfers the indicator to the UTRAN 200, if the attribute of the packet to be 
transmitted is non-real«time or if the status information in the wired line is not requested 
despite that the packet to be transmitted is a real-time packet. That is, the RTCP is not 
used in case of real-time packet transmission. Hence, receiving one indicator informing 
5 the packet transmission of the non-real-time attribute or the other indicator mforming that 
the status information in the wired line is not requested from the core network 300. The 
relay function modules 80a to 80n are not involved in the non-real-time or real-time 
packet transmission and are just turned off. 

MBMS is supported and the relay function modules 80a to 80n determine whether to use 
10 the RTCP packet according to the command of the indicator from the core network 300, 

when a RTP packet is transmitted from the data source 70. The core network 300 

transfers the indicator to the UTRAN 200, if the RTCP packet is used. 

Hence, receiving the indicator from the core network, the relay function modules 80a to 

80n offers the RTCP packet containing the status information of the wired line to the data 
15 source 70 and are not involved in other transmission, which does not use the RTCP 

packet, of the packet of the real-time attribute. Thus, the indicator contains the 

information of informing whether to use the RTCP. 

Referring to FIG. 5, the data source 70 intends to transfer a real-time packet requesting 
status information for real-time packet transmission and a real-time or non-real-time 

2 0 packet failing to request the status information for the real-time packet transmission. 

Once one specific packet transmission is requested from the data source 70, the core 
network 300 sets up a radio access bearer with at least one terminal 100 (SIO). In the 
following description, it is assumed that MBMS radio access bearer is set up to provide 
MBMS to the corresponding terminals. 

25 When the MBMS radio access bearer is set up, the core network 300 determines the 
attribute of packet data to be transmitted from the data source 70 and informs the 
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UTRAN 200 of the detennined attribute. The SGSNs 40a to 40n of the core network 200 
inform the UTRAN 70 whether the packet to be transmitted from the data source 70 has 
the real-time or non-real-time attribute. The SGSN 40 informs the UTRAN 200 whether 
to use RTCP for the transmission of the real-time packet, for which the SGSN 40 uses an 
5 indicator. 

In one embodiment, one indicator indicates whether the packet to be transmitted has the 
non-real-time or real-time attribute. This indicator is a packet attribute indicator. 
Another indicator of informing whether to use the RTCP for the transmission of the real- 
time packet is named an RTCP use/not-use indicator, for example. 

10 Accordingly, the UTRAN 200 determines whether to use the relay function modules 80a 
to 80n based on the received indicator (SI 1). Subsequently, the packet of the data source 
70 is transferred to the RNCs 12a to 12n of the UTRAN 200 (812). The RNCs 12a to 
12n of the UTRAN 200 have already decided whether to use the relay function modules 
80a to 80n by the indicator received from the core network 300 in the process of setting 

15 up the radio access bearer. Therefore, the relay fiinction modules 80a to 80n operate in 
the following two ways for a packet to be received. 

First, if the packet to be received is an RTP packet using RTCP, each of the relay 
function modules 80a to 80n adds status information (e.g., a loss amount of RTP packet) 
in the wired line for the received RTP packet to an RTCP packet and feeds it back to the 
2 0 data source 70 (813). In this case, the RNCs 12a to 12n offer the RTP packet received by 
tunneling or node-to-node communication to the relay function modules 80a to 80n, 
respectively. 

The RNCs 12a to 12n or the relay function modules 80a to 80n transmit the received RTP 
packet to a plurality of terminals 100 in the wireless line (814). In this case, the RTP 
25 packet transmitted to the terminals 100 is broadcasted or multicasted on downlink radio 
chaimel. Meanwhile, the data source 70 having received the RTCP packet determines 
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data size, appropriate encoding scheme, and/or the like of an RTP packet to be 
transmitted based on the status information included in tiie RTCP packet (S 15). 
In one embodiment, the data source 70 changes routing information included in an RTP 
packet to be transmitted later based on the status information included in the RTCP 
5 packet so that RTP packets are prevented from flowing in elements of the core network 
300 and/or the UTRAN 200 where collisions frequently take place (SI 5). 
Moreover, the data source 70 regards the RTCP packets transferred from the relay 
function modules 80a to 80n as being transferred one by one per each wire/wireless line 
termination point and appropriately determines each bandwidth required for the 

1 0 transmissions of the RTP packet and the RTCP packet (S 15). 

Meanwhile, the terminal 100 has already recognized the attribute of the packet to be 
received in the process of setting up the radio access bearer with the core network 300. 
Hence, the corresponding terminal 100 having received the RTP packets generates RTCP 
packet including status information such as the number of RTP packets lost during 

15 transmission m the wireless line, transmission delay time, and the like and then feeds it 
back to the RNCs 12a to 12n or the relay function modules 80a to 80n (SI 6). 
The RNCs 12a to 12n or the relay function modules 80a to 80n perform transmission 
handling on the RTP packet transmitted to the respective terminals 100 in the wireless 
line based on the reception status information acquired from the RTCP packets 

2 0 transmitted from the respective terminals 100 in the wireless line (SI 8). 

In one embodiment, the RNCs 12a to 12n or the relay function modules 80a to 80n 
further feed back the RTCP packets received from the respective terminals 100 to the 
data source 70. The data source then further considers the RTCP packets fed back from 
the respective terminals 100 in determining the data size, appropriate encoding scheme, 

2 5 and/or the like of the RTP packets to be transmitted thereafter. 
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When a packet to be received is an RTP packet using no RTCP or a non-real-time packet, 
i.e. in case that the relay function module 80 is unnecessary for use, the KNCs 12a to 12n 
transmit the packet received via the core network 300 to a plurality of the tenninals 100 
in the wireless line (S18). Where RTCP itself is unused, the tenninals 100 having 
5 received RTP packets take no operational action for generating RTCP packets. 

Accordingly, in the description of the present invention, UTRAN including the relay 
ftinction module transfers RTCP packet to the data source from a termination of wired 
line to preferably perform RTP and RTCP operations. Specifically, RTCP packet 
transmitted from each user equipment is handled in UTRAN so as not to be transferred to 
10 the data source. Hence, waste of radio resources is prevented, and the number of packets 
lost in collision on Internet can be accurately grasped. Therefore, the number of the lost 
packets can be counted, whereby it is able to appropriately control to provide a packet 
service. 

In the present invention, since RTCP packets for controlling RTP packets are generated 
15 from the UTRAN as the end point of the wired line and the iiser equipment as the end 
point of the wireless line, respectively, it is facilitated to discern the statuses of the wire 
and wireless lines. Therefore, the present invention is configured to change the packet 
size and encoding scheme of RTP packets to be transmitted according to the respective 
causes of the wire and wireless lines. 
2 0 For instance, the data source appropriately changes the size and encoding scheme of the 
RTP packet to be transmitted to reduce the loss of the RTP packet to be transmitted, 
whereby data transfer amount can be accurately adjusted. Moreover, the situation of the 
wired line is accurately grasped to efficiently control the wired line. 
In the present invention, since UTRAN manages and controls the wireless line, the 
25 wireless line itself can adjust the data transfer amount and encoding scheme to be 
appropriate for the status of the current wireless line. In the present invention, statuses of 
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the wire and wireless lines are separated from each other, whereby it is able to accurately 
judge whether the loss of the real-time data packets takes place in the wire or wireless 
line as well as to accurately judge the respective packet transmission delay times in the 

wire and wireless lines. 

5 In the present invention, bandwidths for RTP and RTCP can be accurately determined, 
and the overall network can be more effectively controlled by grasping the status of the 
wired line. The system according to the present invention is modified to be appropriate 
for MBMS. MBMS uses RTP and RTCP to transmit real-time data. Hence, the present 
mvention is more effective when the system broadcasts/multicasts real-time packets to 

1 0 user equipments in wireless line for MBMS. 

Finally, in the present invention, when UTRAN uses the relay function module, the 
indicator for operational control of the relay function module is further used to improve 
an operational efficiency of the relay function module. Therefore, the present invention is 
more appropriate for a packet service satisfying specific QoS. 

15 FIG. 6 illustrates a block diagram of mobile station according to the preferred 
embodiment of the present invention. 

Referring to FIG. 6, the mobile station 500 comprises a processor (or digital signal 
processor) 510, RF module 535, power management module 505, antenna 540, battery 
555, display 515, keypad 520, memory 530, SIM card 525 (which maybe optional), 

2 0 speaker 545 and microphone 550. 

A user enters instructional information, such as a telephone number, for example, by 
pushing the buttons of a keypad 520 or by voice activation using the microphone 550. 
The microprocessor 510 receives and processes the instructional information to perform 
the appropriate function, such as to dial the telephone number. Operational data may be 

2 5 retrieved from the Subscriber Identity Module (SIM) card 525 or the memory module 
530 to perform the function. Furthermore, the processor 5 10 may display the 
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instructional and operational information on the display 515 for the user's reference and 
convenience. 

The processor 510 issues instructional information to the RF section 535, to initiate 
communication, for example, transmit radio signals comprising voice communication 
5 data. The RF section 535 comprises a receiver and a transmitter to receive and transmit 
radio signals. An antenna 540 facilitates the transmission and reception of radio signals. 
Upon receiving radio signals, the RF module 535 may forward and convert die signals to 
baseband frequency for processing by the processor 510. The processed signals would be 
transformed into audible or readable information outputted via the speaker 545, for 
10 example. 

It will be apparent to one skilled in the art that the preferred embodiments of the present 
invention can be readily implemented using, for example, a suitably programmed digital 
signal processor (DSP) or other data processing device, either alone or in combination 
with external support logic. 

1 5 The preferred embodiments may be implemented as a method, apparatus or article of 
manufacture using standard programming and/or engineering techniques to produce 
software, firmware, hardware, or any combination thereof The term "article of 
manufacture" as used herein refers to code or logic implemented in hardware logic (e.g., 
an integrated circuit chip, Field Programmable Gate Array (FPGA), Application Specific 

2 0 Integrated Circuit (ASIC), etc.) or a computer readable medium (e.g., magnetic storage 
medium (e.g., hard disk drives, floppy disks, tape, etc.), optical storage (CD-ROMs, 
optical disks, etc.), volatile and non-volatile memory devices (e.g., EEPROMs, ROMs, 
PROMs, RAMs, DRAMs, SRAMs, firmware, progranmiable logic, etc.). Code in flie 
computer readable medium is accessed and executed by a processor. 

2 5 The code in which preferred embodiments are implemented may further be accessible 
through a transmission media or fi-om a file server over a network. Jn such cases, the 
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article of manufacture in which the code is implemented may comprise a transmission 
media, such as a network transmission line, wireless transmission media, signals 
propagating through space, radio waves, infrared signals, etc* Of course, those skilled in 
the art will recognize that many modifications may be made to this configuration without 
5 departing firom the scope of the present invention, and that the article of manufacture may 
comprise any information bearing medium known in the art. 

Industrial Applicability 

It will be apparent to those skilled m the art that various modifications and variations can 
10 be made in the present invention. Thus, it is intended that the present invention covers the 
modifications and variations of this invention provided they come within the scope of the 
appended claims and their equivalents. 
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Claims ; 

1. A method of transferring real-time data from a data source to a mobile device in 
communication with a communications network having a wired communication line and 

5 a wireless communication line, the method comprising: 

receiving the real-time data from the data source over the wired communication 

line; 

determining packet loss for the wired communication line to produce control 

information; 

1 0 transmitting the control information to the data source; and 

transmitting the real-time data to the mobile device based on the control 
information. 

2. The method of claim 1 , further comprising: 

15 determining quality of service data for at least one of the wired or wireless 

communication lines based on the control information. 

3. The method of claim 2, frirther comprising: 

adjusting transmission requirements for the real-time data based on the quality of 
20 service data. 

4. The method of claim 3, wherein the adjusting comprises: 

adjusting transmission size of real-time data packets comprising the real-time data. 

25 5. The method of claim 3, wherein the adjusting comprises: 
adjusting encoding mode of the real-time data. 
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6. The method of claim 3, wherein the adjusting is performed when real-time data is 
transmitted from the data source. 

5 7. The method of claim 2, wherein the quality of service for the wireless 
communication line is determined based on a first quality of service associated with the 
communications network segment that controls communication of real-time data from the 
data source to the mobile device and a second quality of service associated with the wired 
communication line. 

10 

8. The method of claim 2, wherein the quality of service for the wireless 
communication line is determined based on first and second quality of service 
information. 

15 9. The method of claim 8, wherein the first quality of service information is received 
from the mobile device. 

10. The method of claim 8, wherein the second quality of service information is 
determined based on receiving loss packet information for the real-time data 

2 0 conununicated over the wired communication line. 

11. The method of claim 8, wherein the first quality of service information is 
determined based on number of packets lost during communication of the real-time data 
from the data source to the mobile device over the wired and wireless communication 

25 lines. 
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12. The method of claim 1, wherein the real-time data is received and transmitted 
over a real-time transport protocol (RTP). 

13. The method of claim 1, wherein the real-time data is received and transmitted via 
5 a mobile communications network in communication with the data source. 

14. The method of claim 1, wherein a UMTS terrestrial radio access network 
(UTRAN) determines the quality of service for the wireless communication line based on 
first packet loss information received from the mobile device and second packet loss 

1 0 information associated with receiving the data over the wired communication line. 

15. The method of claim 14, wherein the UTRAN comprises a relay function module 
for depacketizing the real-time data received over the wired communication line to 
determining the second packet loss information. 

15 

16. The method of claim 15, wherein the relay function module packetizes the 
depacketized real-time data before transmitting it to the mobile device. 

17. The method of claim 16, wherein the mobile device sends a feedback comprising 
2 0 the first packet loss information to the UTRAN after receiving the real-time data. 

18. The method of claim 1, wherein the real-time data is encapsulated in real-time 
transport protocol (RTP) packets transmitted over user data gram protocol (UDP). 

25 19. The method of claim 18, wherein the real-time data is transported via real-time 
transport control protocol (RTCP). 
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20. The method of claim 19 further comprising determining whether real-time data is 
being transmitted over the RTCP. 

5 21. A real-time data communication system comprising: 

a wired communication system connected to a data source; and 
an interface system for wirelessly connecting the wired communication system to 
a mobile device; 

wherein the interface system adjusts transmission requirements for real-time data 
10 based on first packet loss information associated with real-time data transmitted over the 
wired communication system. 

^ 22. The system of claim 21, wherein a first quality of service is determined based on 
transmission of the real-time data from the data source to the interface system. 

15 

23. The system of claim 21, wherein a second quality of service is determined based 
on transmission of the real-time data from the interface system to the mobile device. 

24. The system of claim 21, wherein the interface system comprises a relay module 
2 0 for processing data transmitted from the data source to the mobile device. 

25. The system of claim 24, wherein if the data transmitted is not real-time data then 
the relay module does not process the data. 

25 26. The system of claim 24, wherein if the data is not transmitted over real-time 
control protocol tibien the relay module does not process the data. 
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27. The system of claim 24, wherein a first quality of service is determined by the 
relay module by depacketizing real-time data transmitted over the real-time control 
protocol to determine packet loss in the wired communication system. 

5 

28. The system of claim 24, wherein a second quality of service is determined by the 
relay module based on feedback provided by mobile device about packet loss detected 
after receipt of real-time data by the mobile device. 

10 29. The method of claim 21 » wherein the real-time data is encapsulated in real-time 
transport protocol (RTF) packets transmitted over user data gram protocol (UDP). 

30. The method of claim 21, wherein the real-time data is transported via real-time 
transport control protocol (RTC3P). 

15 

31. A method of data communication comprising: 

establishing a conmiunication bearer between a data source and a mobile device 
over a communication network comprising wired and wireless communication segments; 
and 

20 adjusting transmission of the real-time data based on quality of service over the 

wired and wireless conununication segments, when data being communicated comprises 
real-time data and is being transmitted over a real-time communication protocol, 

32. The method of claim 31, wherein a relay module determines the quality of service 
25 over the wireless communication segment by receiving feedback from the mobile device 
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over a real-time control protocol and comparing the feed back with quality of service 
information for the wired communication segment. 

33. The method of claim 32, wherein the relay module is incorporated into a 
5 communications network connecting the data source and the mobile device. 



34. The method of claim 33, wherein a radio access bearer (RAB) is established 
between the communications network and the mobile device to provide the relay module 
with quality of service information. 

10 

35. A method of transferring real-time data from a data source to a mobile device 
connected to a wired communication line by way of a wireless communication line, 
wherein a Universal Terrestrial Radio Network (UTRAN) acts as a communication 
interface between the wired and wireless communication lines, the method comprising: 

15 receiving the real-time data from the data source over the wired communication 

line; 

transmitting control information associated with transmission quality of real-time 
data over the wired communication line to the data source; and 

transmitting the real-time data to the mobile device over the wireless 
2 0 communication line based on the control information. 

36. The method of claim 35, further comprising: 

determining quality of service for the wired communication line based on the 
control information. 

25 

37. The method of claim 35, further comprising: 
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adjusting transmission requirements for the real-time data based on the quality of 
service for the wired communication line. 

38. The method of claim 37, wherein the adjusting comprises: 

5 adjusting transmission size of real-time data packets comprising the real-time data. 

39. The method of claim 37, wherein the adjusting comprises: 
adjusting encoding mode of the real-time data. 



10 



40. The method of claim 37, wherein the adjusting is performed when real-time data 
is transmitted from the data source. 
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